Generally, when data is updated in a distributed database, it is necessary to perform the synchronization between a master site database and a slave site database and maintain the consistency of data between the sites. In the distributed database, the synchronization in the data update is performed in a scheme called a two-phase commit.
In the two-phase commit, the commit control is performed separately in the first phase and the second phase.
In the first phase, the master site database transmits an update request to the slave site database. In the second phase, the master site database receives a response about the updatability from the slave site database, determines commit or abort based on the response, and notifies the slave site of the determination result. In the slave site, commit or rollback is executed based on the determination result received from the master site. In the two-phase commit, it is required that the slave site database maintains the “secure state” in which both commit and rollback can be performed while data can be updated from when an update request is received to when the determination result is reported.
FIG. 12 is a schematic diagram illustrating the method in a first phase of the two-phase commit in a general distributed database. In FIG. 12, the master site database is an integrated database 1001, and the slave site database is an element database 1002 (1002-1, 1002-2).
As illustrated in FIG. 12, in the first phase, the integrated database 1001 first notifies the element databases 1002-1 and 1002-2 of an update request, and inquires whether commit can be performed (FIG. 12(A)). The element database 1002-1 prepares for an update, and returns a response of “request for commit” to the integrated database 1001 while maintaining the secure state, if the update can be performed. The element database 1002-2 returns a response of “request for rollback” to the integrated database 1001 if the update cannot be performed.
In the second phase, the integrated database 1001 determines commit or rollback depending on the response from the element database 1002. In the determination, rollback is selected if there is any rollback response returned. The integrated database 1001 notifies the element database 1002 of the determination result. The element database performs commit or rollback process according to the notification from the integrated database 1001. In the case of the example in FIG. 12, the integrated database 1001 determines the rollback, and notifies the element databases 1002-1 and 1002-2 of the rollback. Upon receipt of the notification, the element databases 1002-1 and 1002-2 perform the rollback process.
Thus, in a general distributed database, the consistency of data held in each site is to be maintained by performing the synchronization between the master site database and the slave site database by the two-phase commit when data is updated.
However, in an FCMDB (Federated Configuration Management Database) system in which the configuration information about an IT system (information technology) is virtually and integrally managed, the two-phase commit cannot be applied.
The FCMDB system is described below. The FCMDB system is a database system in accordance with an ITIL (Information Technology Infrastructure Library). FIG. 13 illustrates the entire configuration of the FCMDB system.
An FCMDB system 10 is a distributed database system having a plurality of MDRs (Management Data Repositories) 12 (MDR1, MDR2, . . . , and MDRn) and an FCMDB 11 which virtually integrates the MDRs 12. Each of the MDRs 12 is a CMDB (Configuration Management Database) which manages a large amount of CIs (Configuration Items) and associates the CIs with each other. The FCMDB 11 itself is also a CMDB. In the CMDB, the CI is implemented as the configuration information (attribute information) about the resource configuring the IT system. The CMDB manages the CIs as associated with each other, and the association is referred to as a relationship.
FIG. 14 is an example of the distribution of the configuration information about the same resources in the FCMDB system.
In the FCMDB system, the configuration information of the same resources may be doubly registered in a plurality of MDRs. In the FCMDB system 10 illustrated in FIG. 14, the configuration information about the server A is registered in an MDR 12-1 (MDR1) and an MDR 12-2 (MDR2). The MDR 12-1 manages the information about a CPU (central processing unit) 31, memory 32, and a power supply (@power) 33 as the configuration information about a server 30 (A). The MDR 12-2 manages the information about the CPU 31, an HDD (hard disk device) 34, and the power supply 33 as the configuration information about the server A. Therefore, in this example, the CPU 31 and the power supply 33 in the components of the server A are doubly registered in the MDRs 12-1 and 12-2. In this example, the server 30, the CPU 31, the memory 32, and the HDD 34 are respective CIs.
Upon receiving the information register request from the MDR 12, the FCMDB 11 manages the configuration information about the resources. The FCMDB 11 manages not only the contents (for example, “value”) but may also manage only the position information (pointer). The FCMDB 11 (1) determines whether or not there is an item that is doubly managed, (2) determines whether or not the information managed by a specific MDR 12 is to be held as the “primary information” about the item if there is a doubly managed item, and (3) holds the meta-information about which MDR 12 is a primary MDR (that manages the primary information) and which MDR 12 is a secondary MDR (that manages the secondary information), for each item of the resources managed by the MDRs 12-1 and 12-2.
What reads the information from the FCMDB system 10 and uses the information is called a “client”. There is a data provider behind the MDR 12 to input data to the MDR 12. It is a typical operation management middleware. Operation management middleware reads data managed on a report, and detects and monitors an actual management target machine over a network.
As illustrated in the schematic diagram in FIG. 14, there are a plurality of MDRs which hold the configuration information about the same resources in the FCMDB system. Therefore, when there is an update request from an MDR to an FCMDB for the configuration information about a resource, it is necessary to also update the configuration information in other MDR which holds the configuration information about the resource. When the update is synchronously performed, the two-phase commit cannot be used in the FCMDB system because not all MDRs consider the participation in the distributed database in the FCMDB system. Therefore, the following problems (1) and (2) occur.
(1) There is an MDR which cannot return a response to the update request from the FCMDB while maintaining the secure state. This problem is caused by the fact that the FCMDB system is not an organized environment such as a distributed database etc., but a group of existing data storage (which may not be databases). Therefore, in the FCMDB system, there is an MDR in the FCMDB system which cannot securely check the updatability (if a response is prioritized, data is updated in a state where rollback is disabled, and on the other hand, the data update process cannot be started and no response can be returned if the secure state is prioritized).
(2) At the update request from the FCMDB, a response of the MDR may be severely delayed. This problem is caused by the fact that there may be a determination of a human in the response of the MDR. In the case of the two-phase commit, a reply to an update request is awaited for a specified time or longer, and when the time passes, it is determined that the participant who has transmitted the update request is in an abnormal state. However, it is not preferable to wait for the reply as described above because it reduces the performance of the entire system.
FIG. 15 is a schematic diagram illustrating the factor of inapplicability of the two-phase commit to the information update (data update) of MDR in the FCMDB system.
In the first phase of the two-phase commit, the FCMDB 11 inquires of the MDRs 12-1 and 12-2 whether or not the update can be performed (FIG. 15(A)). In this example, as illustrated in FIG. 15(B), when the update request is received from the FCMDB 11, the MDR 12-1 is in an insecure state (corresponding to the reason (1) above). Therefore, the MDR 12-1 returns to the FCMDB 11 a response that represents “the update has been performed, and the information cannot be restored”. The MDR 12-2 requires an operation of a user in updating information, and it takes a long time to return a response to the FCMDB 11 (corresponding to the reason (2) above).
As described above, the two-phase commit cannot be used in the synchronization of the data (information) update in the FCMDB system.
In the general distributed database, an invention of a method of shortening the processing time for data update by the two-phase commit is known (Patent Document 1). Patent Document 1: Japanese Laid-open Patent Publication No. 6-119227